This application relates generally to the coupling of field devices to a network and more particularly to the coupling of field devices through a network platform to control logic located within the network.
Field devices such as thermocouples, sensors, motor starters, valves and others have special needs not typically addressed by the commercial networking industry. These needs include industrial hardening (the factory floor is often a much harsher environment than that of the typical office), linear connection topology requirements, cost sensitivity (cost per point for an Signal interface (I/O) device connection is important), and packaging issues (e.g., NEMA enclosures or various agency approvals create radically different packaging and power requirements than office devices). As a result of the specialized requirements for such field devices, vendors have created a plethora of pseudo-standard networks, including DeviceNet(trademark), Profibus(trademark), and ASI and FieldBus(trademark) to couple field devices to controlling logic contained within, e.g., programmable logic controller (PLC) processors, or other industrial controllers. Such networks form the I/O and Device Network layer of industrial control networks. Field devices may be denoted as either xe2x80x9csmartxe2x80x9d devices if they can directly access the network layer or xe2x80x9cdumbxe2x80x9d if they require an intermediate I/O system to access the network layer.
Above the I/O and Device Network layer, the PLC processors, industrial controllers and other intelligent devices containing controlling logic are coupled to a control network. This network, which functions as the Control and Information Network layer and accommodates peer-to-peer messaging, PLC processor interlocking and other functions, is also pseudo-standard. The relationship of the pseudo-standard device and control layers to an enterprise LAN in prior art control systems is illustrated in FIG. 1.
Upon inspection of FIG. 1, it will be noted that existing control systems utilize a gateway approach to physically segment traffic in the control and monitoring system. In the prior art system illustrated, these gateways take the form of the Industrial Controller and the IBM Compatible PCs. Newton""s Telecom Dictionary defines a gateway as follows:
Typically referred to as a node on a network that connects to otherwise incompatible networks . . . Thus, gateways on data networks often perform data and protocol conversion processes . . . According to the OSI model, a gateway provides a mapping of all seven layers of the model.
Gateways are needed because devices on the (typically IP based) Enterprise LAN cannot communicate directly with devices on the incompatible pseudo-standard control network. This gateway approach of prior art control systems has historically been done for a number of reasons including the previously described specialized requirements of field devices.
Another reason is the time critical nature of I/O and Device traffic. To guarantee that the field devices would have unobstructed access to interact with essential control logic, the I/O and Device level traffic was physically segmented from higher level network traffic. Thus, the control engine had direct access to the I/O and Device traffic through a dedicated connection, e.g., an Allen-Bradley PLC5 Industrial Controller""s control engine can communicate with I/O modules directly via its proprietary backplane. Similarly, a DeviceNet(trademark) interface card can be plugged in and the control engine can communicate with smart devices. Such a controller may be connected to another higher level network like ControlNet(trademark) or Ethernet, but peers on the network can only access the controller""s I/O information by going xe2x80x9cthroughxe2x80x9d the controller""s control engine. In this fashion, the control engine is the gateway; any interaction with the I/O by a peer node on the higher level network is constrained by the controller""s engine.
But the gateways in prior art control systems create a number of problems. For example, gateways are tremendously inefficient and side effect ridden. They also require applications to be target network specific. For instance, an application must still be written for xe2x80x9cDeviceNet(trademark)xe2x80x9d although it might be connected only to xe2x80x9cEthernetxe2x80x9d because it will be communicating with an Ethernet to DeviceNet(trademark) gateway, which is essentially an encapsulation of DeviceNet(trademark) protocol on the Ethernet link. In addition, there are always some issues and incompatibilities involved with writing an application that communicates directly with the target network vs. an application that communicates with a target network through a gateway. Thus, there is a need in the art for a new kind of control system which will be open at all levels and obviate the need for a gateway.
The present invention provides a network platform that allows industrial field devices such as thermocouples, sensors, motor starters, valves and the like to directly communicate with an IP-based enterprise network, thereby producing an open control system. The field devices may produce either an analog or a digital output signal for transmission to the network platform. In turn, the network platform may transmit either an analog or a digital input signal to the field devices. Devices on the IP-based enterprise network may communicate directly with the field devices through the network platform. In particular, control logic, which resides on the enterprise network, may interact with the field devices through the network platform.
The resulting control system comprising the IP-based enterprise network, the network platform and the field devices is open in that the network platform follows the IP-based protocol of the enterprise network. Thus, the field devices are essentially equal peers with the remaining devices on the enterprise network. In a preferred embodiment, the network platform prioritizes traffic so that a Quality of Service (QoS) may be guaranteed for a particular class of traffic. A network switch or other form of arbitrator within the network platform distinguishes between the various classes of traffic, giving priority according to the criticality of the traffic class.
The network platform may comprise a backplane for providing communication, power and field connections for other components within the network platform. Signal interface modules coupled to the backplane provide the translation of signals between the field devices into a form suitable for transmission on the backplane. The backplane couples the translated signals to a device module that functions to convert the translated signals into IP-based signals that other participants on the IP-based network will recognize. A network switch or other form of arbitrator couples between the IP-based network and the converted IP-based signals to increase the available bandwidth between the field devices and other peers on the IP-based network.